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Good afternoon everyone! Thanks for sticking with us all the way to this, the last talk 
in the last hour on the last day of GDC. 

I'm Elan Ruskin and today I'm going to talk at you about dialog in games, and how to 
build a system that lets your writers make it as they do best. 
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Hard to keep up taking notes? 

Taking pictures of every slide? 

Relax, slides will be at: 

valvesoftware.com/publications.html 

And my blog: 

assemblyrequired.crashworks.org 
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What is this talk about? 

• A system for tracking lots of facts and then 
picking a rule from a database based on 
matching criteria 

• Originally used for character speech in Half-Life 
2, Team Fortress 2, Left4Dead, Portal 2, Dota2,... 

• Can also drive animation, sound, Al, gameplay 
logic, and many other things 


Today we're going to talk about a system we have for tracking a whole bunch of state 
about the world in a uniformly manageable way, and then using that state to select 
just the right line from a big database of character speech. It's the system we used in 
The Orange Box, Left4Dead, Portal, Dota.... All our games. You can use the same 
mechanism to drive things other than character dialog, although that didn't occur to 
us until after we had built it. 


Who is this talk for? 

Programmers and writers. 

Programmers will see how to build a system for creating Als that 
dynamically generate dialog based on world state, and possible 
extension into other fields via script. 

Writers will see the possibilities of such a system, and suggestions for 
how to create an interface that allows them to generate content easily. 
What's this about? 

Dynamic game dialog, the code behind the engine that drives ours, and 
thoughts on how to design games around such dialog and dialog around 
games. 

And then how you can extend the system to drive other things 
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Shakespearicles, the strongest writer who ever lived 


What is this talk about? 

• Empowering Writers! 

• A philosophy of character 
dialog and behavior 

• Tracking lots and lots of 
context to drive gameplay 


But more importantly today's talk is about empowering writers. You can't have dialog 
without writers, and making writers' lives easy is the best way to get good dialog. So 
this is mostly about how to generally think about world state and character behavior 
in a way that enables writers to create and iterate independently. 
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Response Rules: context tracking that is 

1. Simple 


2. General 

3. Efficient 

4. Friendly 


SIMPLE = FRIENDLY 


We've tried to make a system that is as simple as possible, general enough for many 
features in all our games, efficient enough to be used at runtime, and user-friendly 
for the writers who populate it. This is actually three things, not four, because I firmly 
believe that simple and friendly are the same thing. A system that is simple to use 
gets used. A system that is simple to write gets maintained. 
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Why talk about dialog? 


Why stand here and talk for an hour about talking? Well, there have been a bunch of 
games recently that I think did interesting and successful things with dialog that... 

... was an artistic element of the game 
... remembered and responded to the player's actions 
... created character and environment 
... or was just plain fun. 

I don't know how they did their stuff, but I know how we did it, and I think our system 
could enable people to make more games like these. I liked all these games, so I want 
people to make more like them, so I can play them! My ulterior motive. 
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The Problem of Contextual Dialog 

• /e dialog that 
responds to 
player actions and 
world state 

• In the beginning 
this was simple 


Moonm/st( I nfocom, 1986) 



By "contextual" or "dynamic"' dialog I just mean any system where characters speak, 
and the speech seems to respond to players' actions, the state of the world around 
them, and previous events. In the beginning, when games were nothing *but* dialog, 
this was pretty straightforward. 
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Dialog 


Fallout 


The Problem of Contextual 


• But it quickly got 
complicated 

• Some games used 
trees to create 
choice, and stored 
explicit flags 

• But that gets 
unwieldy pretty fast 


Things got complicated pretty fast after that. Early RPGs introduced the notion of 
conversation trees, so players could have back-and-forth with characters, but those 
got big. Also, you might want a character to remember the fact that you blew up their 
home village three missions ago, and pick a different tree based on that, so that 
entailed keeping a bunch of global state and control flow which gets unwieldy very 
quickly. 
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The Problem of Contextual Dialog 

• Some games have 
characters "bark"' based 
on what the player does 

• Example: stealth games 

• Used to convey Al state 



"What's in that shadow over there? I'd better check it out." 


Some games don't have conversation trees, but they have Al charactgers who "bark", 
or speak spontaneously, to announce their state or forward the story. For stealth 
games this is a critical game mechanic, because a big part of the game is the player 
being aware of what the Al knows, what it's planning on doing, and generally keeping 
track of the Al's state of mind. Having an Al that clearly communicates its intentions is 
a critical part of the game. 
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Conveying Al state 


A great example of this is Batman; Arkham City. (I love that game. So much good stuff 
in it!) 

This game has a bunch of different characters who convey state in stealth sequences. 
One of them is so clear and straightforward that it's like it was tailor made for 
demonstrating! 


(video) Example: the TYGER guards in Batman Arkham City, who actually say 
things like "Target has been sighted!" "Converging on last known location!" 
"Enemy object found! Initiating search!" "Scanning in dark areas!" and so on. 


10 










: DEVELOPERS CONFERENCE 


MARCH! 


^GDCONF.I 



Conveying Al state 


A great example of this is Batman; Arkham City. (I love that game. So much good stuff 
in it!) 

This game has a bunch of different characters who convey state in stealth sequences. 
One of them is so clear and straightforward that it's like it was tailor made for 
demonstrating! 


(video) Example: the TYGER guards in Batman Arkham City, who actually say 
things like "Target has been sighted!" "Converging on last known location!" 
"Enemy object found! Initiating search!" "Scanning in dark areas!" and so on. 


11 








: DEVELOPERS CONFERENCE 


MARCH! 


^GDCONF.I 



Used as an artistic or narrative device 


Bastion 

(Supergiant, 2011) 


Some games use contextual speech as an artistic device. Bastion has an omniscient narrator 
who seems to respond to everything the player does. That's not because the player needs 
the game to tell him what he's doing, of course, but because that's what the game is *about* 
-- storytelling, and creating a world from your actions. 
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Madden 2011 (EA) 


Some games need more than if-else 


Sports 


commentators 
generate thousands 
of potential lines for 
highly dynamic 
circumstances. 


Sports games have elaborate commentators that somehow assemble tens of 
thousands of possible utterances from thousands of individual snippets about this 
hugely dynamic environment that can get into I don't know how many possible 
situations. Handling all of this by just a forest of if-else would be painful. 
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Some games have lots of state 


• Player history and world events factor into dialog choices, character outcomes. 

• Varied, context-sensitive speech possibilities for "townsfolk" outside converation trees 

• suggest a living world 

• prevent characters from falling back on generic, repetitive lines. 


And think about modern RPGs and all the state they track! Mass Effect and Skyrim 
have to remember a huge library of things that the player's done all over the world. It 
affects conversation possibilities and the character stories avaialble; but it's also 
useful to create the feeling of a living world from just the passerby barks. If ordinary 
townspeople remember that you are the elven mage that saved their village from the 
demon horde, and interact with you differently based on that, you feel much more 
like a part of the world than you would if they just said the same canned line over and 
over. 
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There are many systems, 
this one is ours. 


Like I said, I don't know how they implemented their stuff, but here's the way we do 
it. I think it would work pretty well to make games like those, and maybe it'll work 
well for you. 
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One simple, uniform way to... 

• Track lots of State in a dynamic game 

• Find the right line for every circumstance 

- Special lines for specific cases 

- General lines for all the rest 

• Allow writers to create and iterate a powerful rules- 
driven system 

- Programming a book of "rules" with "criteria" 

- Not dense if/else trees and function calls! 


Our system was designed to be simple - SIMPLE - and uniform. We wanted one 
straightforward way to track all the state of a game that could possibly be used to 
select dialog, and a convenient way for writers to specify which pieces of state select 
which bits of voice. We want writers driving as much of the dialog-creation process as 
possible, because... that's what they're there for. 
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So, a quick bit of history about the system's early origins. Team Fortress 2 is a 
multiplayer game where players choose from one of nine character classes. Each of 
the characters has its own voice. So, we have a mechanism for allowing players to 
communicate in the voice of their character. 
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Team Fortress 2: player-triggered lines 


If, for example, I'm playing a soldier character and I'm injured and I need medical 
attention, I can hit a button on my keyboard to say that in the voice of my character. 

("MEDIC!!!") 

A!!owing p!ayers to communicate simpie orders to each other in their characters' 
voice encourages roiepiaying and immersion, but it a!so heips internationa! p!ay. If I'm 
playing in the United States, I'!! hear my soldier speak English, but if you're playing 
with me from Spain, then you'll hear his localized voice in Spanish. So this is a way for 
players to communicate with each other across language boundaries. 
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Team Fortress 2: player-triggered lines 


"Need a dispenser here!" 
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Other times you want characters to automatically announce important state without 
the intervention of the player. For example, if I'm playing near a medic, and the medic 
is ready to deploy his uber-heal-ray, I need to know about that whether the player 
controlling the medic remembers to tell me or not. Having characters announce such 
state on their own is an important prompt to players about actions they may need to 
take. 
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TF2: automatic state announcement 


"We must stop tiny cart!" 
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TF2: automatic state announcement 


"Sentry going up!" 
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TF2: player triggered with context 



Player 

clicks 

generic 

"vocalize" 

button 


We also had a mechanism for contextual player-initiated dialog - basically you can 
put your cursor over an object in the world, hit the "vocalize" button, and have the 
game try to figure out what you probably mean and have the character say it in their 
voice. This is sometimes more convenient than speaking at length, and it allows a bit 
of role-playing. 
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It's also an opportunity for us to play up allegiances and rivalries between characters 
in the game world - scout vs heavy, sniper vs spy, for example; the character voices 
gibe at each other and create a bit of storytelling automatically while the players just 
play their game. 

"the enginer is a spy!" 
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TF2: Contextual vocalize button 


"the scout is a spy!" 
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TF2: Contextual vocalize button 


"The spy is... a double agent!" 
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An internal design experiment 

• World premiere of almost never befnrp <;ppn pnntpnt 



mOBOTS, 

BHlWBtHGH 


(don't ask) 


Voices by Richard Lord, lestyn Bleasdale-Shepard 


After The Orange Box, Valve did something kind of... Valve. 

We'd just finished this big (cluster of) games, and we weren't quite ready to go into 
production on the next one. So we decided to take a little time to come up with new 
ideas. We divided the old team into lots of little groups, like 3 or 5 people apiece, 
with each group trying to come up with some new design idea, some feature, some 
experiment that we could roll into a future game. It was a chance to try out risky 
ideas. 

One team chose to explore companion characters - what could we do to make 
friendly characters who seemed more aware of their environment and the player? 
Who had memories and felt like they grew along with the player's experience? We 
took a bunch of Half Life art assets, built a couple of character models, had an artist 
and a programmer supply voices, and came up with .... TWO BOTS ONE WRENCH. 

I was going to say "here, an internal project shown for the FIRST TIME EVER at GDC," 
but I've just been told that Geoff Keighley has shown these assets once before. So 
here, for the... second time ever... the making of an internal design experiment. 
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Environment-aware speech 

• Objects are tagged by name (eg ''soda_can" 
"radiator") 




Tag = "soda_can" 



Tag = "barrel" 


Tag = "bird" 


First we asked, "what's the easiest, simplest way we can prototype making characters 
aware of their environment?" 

Well, we had that code from Team Fortress that we used to find contextual dialog 
based on what the player's cursor was over. 

So we exploited the same tech. We marked each object in the world with a unique 
string class name. 
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Environment-aware speech 



I CONCEPTfcRITERION | 


onSee soda can 


onSee barrel 

onSee radiator 

onSee bottle 


— 


vox_barrel 


Easy as ti! 


Then each robot simply polls its field of vision every few seconds. If it finds an object 
there, it tries to find a line in its database corresponding to the object's tag. If there's 
a match, it plays. 

Super simple. 


Objects are tagged by name (eg "soda_can", "radiator") 

Database stores possible lines indexed by object name 

Characters poll their field of vision for objects in world. If a line matches, say it. 

Easy as n! 
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Video available via 

http://assemblvrequired.crashworks.org/gdc2012-dvnamic-dialog/ 
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This is all the code it took to pull it off. Script, really - we call them response rules. To 
create a new line about an object, a writer just needed to add a new stanza to this in 
Notepad, with an additional criterion for the object's tag name. If there wasn't a line 
for an object, nothing plays. Since we poll every object, adding a new bit of dialog just 
means adding a new rule. Four lines of text-one of them is the name of the vox file 
to play. 
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starting a conversation 



vox sodacan 2 


vox barrel 2 y 


vox_radiator_2 


Walking around reading signs is all well and good, but we wanted characters to talk to 
each other. And there's lots of ways that you can handle conversation in games - 
create scripted sequences, entities that lock down the two characters, some kind of 
purposebuilt statekeeping for conversation. But that's a lot of work, and I'm always in 
a hurry. So once again, we asked, what's the simplest possible way we can do this? 
And we figured that the same way we had the robot poll its vision every few seconds, 
and send itself a "onSee" event with the name of the object if something were there; 
we could have each line of dialog by the red robot dispatch an "onReply" event to the 
blue robot when it was finished. The same way we paramterized onSee with the 
object name we paramterize onReply with a unique tag for the bit said by the first 
robot. If the second robot has a reply, it plays; possibly it triggers a reply on the first 
robot, and back and forth. Again, brain-dead simple. 

// 

Every line said by a bot also gets a name tag, eg "redbot_danger_flammable" 

When red bot finishes speaking, automatically triggers a lookup on the blue bot 
If blue bot has a rule in its database matching the redbot's followup tag, then it plays. 
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Video available via 

http://assemblvrequired.crashworks.org/gdc2012-dvnamic-dialog/ 
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Memory and Context 

• Rules can also write context back to the character 
or the world 

• This context is appended to the next query 
performed by the character. 

• Creates memory, the ability to pick subsequent 
lines based on what happened before. 


Well, if you've got conversation, then you *need* running gags. We wanted 
companion characters that had memory; that reacted differntly based on what the 
player had done near and to them before. Again, what was the simplest, easiest way 
we could do this? 

We figured we could add just one more little bit of technology. The same way all the 
previous rules were parameterized by *eg* the object seen, along with other criteria; 
we figured we could create a table of "memory" in the character's head and then 
send that along with every voice query it made. 
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So here you can imagine that we have a bunch of rules where the matching criteria 
are not just "what am I looking at?" but also an arbitrary "seen_barrels" variable. The 
first time a robot sees a barrel, the first rule matches. It plays the first line, but it also 
sets a bit of state back in the robot's head. 

Photo of barrel via Wikimedia Commons. 
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Memory and Context 



name 

redBot 

seenBarrels 

1 


OBJECT 

SEEN_ 

BARRELS 

RESPONSE 

REMEMBER 

barrel 

0 

vox barrel 0 


A barrel 

1 

^^ox barrel l 

seenBarrels+= 1 

/ barrel 

2 

vox_barrel_2 

seenBarrels+= 1 

bottle 


voxbottle 



So the next time the robot sees a barrel, it matches the second rule in the database - 
the one with a different seen_barrels criterion. The criterion name is arbitrary; it's 
just what the writer chose to name the variable in the robot's head. 
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Memory and Context 


rule BluBot_ObjectSee_Barrel_A 


ot_ObjectSee_Barrel_B 

criteria 

response 

remember 

trigger 


rule RedBot_Friend_Saw_Barrel 


ConceptSeeObject NotInCombat ObjectName=Barrel SeenBarrels=e 
BluBot_BarrelA // hey Look, a barret! 

SeenBarrels :=1 


ConceptSeeObject NotInCombat ObjectName=Barrel SeenBarrels=l 
BluBotBarrelB // a second barret! 

SeenBarrels: =2 
RedBot SeenBarrel 


"Then" rules can also write context back to the character or the world 
This context is appended to the next query performed by the character. 
Creates memory, the ability to pick subsequent lines based on what happened 
before. 


37 










Video available via 

http://assemblvrequired.crashworks.org/gdc2012-dvnamic-dialog/ 
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Left4Dead is a game about four people - you and your friends - fighting against a 
zombie horde. It is designed for replay, so you'll go through each campaign many 
many times. That means we need wide variety; otherwise if you hear the exact same 
canned lines at the exact same points over and over, it becomes dull very quickly. 
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Why Left4Dead (1 & 2) needed more 


We have a complex Al "director" to create that variety, by dynamically responding to 
player actions, throwing different enemies at them each time, and generally trying to 
keep it fresh. 

You can see why a basic system of brush triggers playing canned lines won't work 
here. For one thing, events don't always happen in the same place in the same order; 
you can't have Nick, the Gambler, play a line about the hunter-zombie every time he 
walks into the warehouse, because it may not be there on a given playthrough. Also, 
with each level played so many times, that degree of repetition would be really 
painful; you need much more variety in the placement and nature of the canned 
speech. 
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Why Left4Dead (1 & 2) needed more 


And not every survivor makes it to the end! At any point in the map, you may have 
only some subset of the survivors with you; the others may be dead or straggling. So 
the system needs to cope with having different sets of characters available at each 
point in the map. 
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Here's an example of what I mean by variety. This is the exact same location of the 
exact same mission, but on two successive playthroughs. 

Video available via 

http://assemblvrequired.crashworks.orR/gdc2012-dvnamic-dialog/ 
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We also needed a way for the Al characters to shout out important facts in the world. 
If I'm playing with my friends, and one of them sees an ammo cache in a dark corner, 
then my friend can just tell me. That's an important thing to know; the ammo is in 
different places every time. But you don't always have four humans in a game; we 
have hots that fill in for missing players, and a single player mode. I still need the Als 
to convey that kind of information as if they were humans. So we needed context- 
triggered speech that the hots could play to call out things like weapon caches, as if 
they were humans, and without level designer markup. Once we did it for the hots, 
we realized it was pretty cool for the human-controlled characters to do it also; it's a 
bit of additoinal roleplaying, and more convenient than having to call out yourself. 

Video available via 

http://assemblvrequired.crashworks.org/gdc2012-dvnamic-dialog/ 


43 










: DEVELOPERS CONFERENCE 


MARCH! 


^GDCONF.I 



Left4Dead2 environment-triggered dialog 


Left4Dead is a game that tells its story through the environment. We don't have much 
in the way of cutscenes; the story of the zombie apocalypse is told through the things 
that you see around you as you move through the world. So, the best way we had for 
characters to tell their stories, to express who they are and show their development, 
was through having them remark on the environment also. That's a chance for 
running gags too. 

Video available via 

http://assemblvrequired.crashworks.org/gdc2012-dvnamic-dialog/ 
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Scaling up and up! 

• Left4Dead2 had -10,000 lines of dialog 

• Four main characters interacting with 

- Each other 

- Environments 

- 12 special zombie subtypes 

- Map-specific characters / situations 

- Special game modes (survival, versus, etc) 


The Left4Dead series had more dialog than any of our games to date - over ten 
thousand lines. That's moderate by RPG standards but it's more than we'd ever had in 
an FPS. So we also wanted a system that could manage script and speech at high 
scale. 
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The important thing about dialog is not the code. It is the writers. Writers make 
dialog. That's what you pay them for! 

In a lot of games, the Al programmer looks at all the events that happen to a 
character, and tries to guess, "well, for which events would this character want to say 
something?" The programmer puts in code hooks for each of the sites he can think of 
and then hands the writer a big spreadsheet and says, "okay, fill out a line for each of 
these events." 

Well, the problem with this is you're basically reducing your writers to filling out a 
series of mad-libs. That kind of cramps their style. It also means that it's really the 
programmers doing the writing, and the intersection between the set of good 
programmers and the set of good writers is pretty small (unless you've got Vernor 
Vinge or Ted Chiang working for you). 

Also, any time the writer finds a new circumstance in which she'd want to have a line, 
she has to go back to the programmer and ask for a new code hook to be put in. 
That's slow and it means less stuff gets written. So we really wanted a way for writers 
to decide which circumstances got lines and how finely those lines were specialized. 

... and I get to make the last arrow-to-the-knee joke of this conference. 
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How It Works 


Everything should be made as simple as 
possible, but no simpler. 

— Albert Einstein (probably) 


Now let's go behind the curtain to see how it works. The basic idea is really simple. 
Like, head-slappingly "it's so obvious in retrospect" simple. That's what makes it user 
friendly. 

Remember also that it grew by accretion. It wasn't designed; it kind of evolved as the 
writers made suggestions over the course of several games. If we'd set out to design 
something like this, we probably couldn't have come up with something so simple. 
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Here is the basic idea behind the system. 

You have a database of rules, each with a list of criteria about the state of the world 
that must be met for the rule to be considered a match. A rule has an associated 
"response" which is simply the thing that happens when a rule matches, such as a 
voice file or an animation. When it is time to say a line, a query is constructed of 
many key-value pairs. The database searches for the rule with criteria best matching 
the data in the query; if one is found, the response is sent to the character, who 
utters it as dialog. 
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Key concepts 

• Context (aka "Fact") 

• Query 

• Criterion 

• Rule 

• Response 


A "context" or "fact" is a piece of world state. Like "current map is swamp." 

A query is a pile of those glued together. All the state of the world, used to lookup an 
action. 

A criterion is a single function that returns true or false for a piece of world state. Like 
"zombies greater than 3." 

A rule is a list of a criteria, all which must be true for the rule to "match." 
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Thinking of the world as a pile of facts 

if ( 

( this->name == "Protagonus” ) && 

( globals->GetCurMap()->name == "Cave Of Troglodus” ) && 

( globals->GetKilled( kENEMY_WOLF ) == 8 ) && 

( savedstate->Get("Townl”)->Get("King”)->ni_isAlive ) && 

( !savedstate->Get("Townl”)->Get("Cobbler”)->m_isAlive ) && 

( player->GetInventory()->Get( "HammerOfSmiting” ) != NULL ) && 

( player->GetAllies()->GetNearest()->name == "Bob the Bludgeoner” ) & 
( world->FindEntitiesNear( player->GetLoc(), 
kTYPE_ENEMY ).count() == 3 ) 

( globals->Quests.Get(3)->m_isComplete ) 

( ((C_Orb*) 

(player->GetInventory()->Get( "MagicOrb” ))->GetCharges() == 12 ) 

) 


Programmers are used to thinking of the world as a bunch of facts strewn hither and 
yon. If I want to have an action that occurs when the player is in the cave and the 
wolves have been killed and his ally is nearby and so on, then I can code it by building 
a huge conditional intersection of a bunch of member variables and function calls. 

There's a few things painful about this. 

First, it's not discoverable what kind of data you have available to make a decision. 
You sort of have to know a priori what information is present for you to test (typically 
by having put it there yourself) and where to go looking for it. If you don't know that 
there's a saved state object that tracks the lives of every person in every town, you 
may not even think to make special cases that depend on that. 

Also, it's nonobvious how you get information from all of these sources. There may 
be a complex chain of members and functions between wherever you're writing your 
code and the information you need for your logic. 

Finally, it's just plain messy. Look at that. Confusing. 
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B 

Thinking of the world as a list of facts 


Who 

CurrentMap 
WolvesKilled 
Townl.King.Killed 
Townl.Cobbler.Killed 
Player'. HasHammer'Of Smiting 
Player'. Nearest Ally 
Player.EnemiesNeanby 
Quests.complete 
MagicOrb.charges 


= Protagonus 
= ''Cave Of Troglodus^" 

= 8 

= false 
= true 
= true 

= "Bob the Bludgeoner" 
= 3 

= true 
= 12 


It's much easier and more natural to think of the world as a flat pile of facts. If you 
always pull every piece of information together into a flat dictionary - use sub¬ 
namespaces if you like - it's always clear what you have available to select login 
upon; just look at the query. Also, it's easy to find an individual bit of state in this tree; 
it's just a key lookup. If you always pull all the state of the world into a flat 
representation every time you look for a rule, then it's very simple to add new and 
more specific rules: you don't need to remember which pieces of world state are 
available in queries under which system. You've always got the whole world at your 
fingertips. 

Plus, it's just plain easier for non-programmers to think of state like this. 
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Context (aka "Fact") 

• A piece of world state. 

• a key:value pair, such as: 

• ''who": "louis" 

• "hitpoints":57 

• "object_under_cursor" : "urinebarrel_2" 

• Keys are strings 

• values may be numbers, handles, or strings 


An individual "context" or "fact" is just a pair - a keyname string, and a variant value 
(any type). Like "hitpoints are 57". 
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Context (aka "Fact") 

• A piece of world state. 

• a key:value pair, such as: 

• ''who": "louis" 

• "hitpoints":57 

• "object_under_cursor" : "urinebarrel_2" 

• Keys are strings symbols 

• values may be numbers, handles, or str i ngs symbols 


Don't actually use strings, of course. Use symbols or interned strings instead. I'm just 
using "strings" as a shorthand for "human readable unique identifier." 
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Query 

• A list of Facts used to select a rule. 

• Facts collected into a long tuple of {k:v} pairs, like 

{ "who";"louis", "hitpoints":57, "nearest_ally":"zoey",...} 

• ie an associative array of keys to variant data. 

• Typically hundreds of items long. 

• Certain key names are special. 

- ''concept" is used to select the general type of speech 
requested 

- "who" always indicates the speaking character 


Thus a query "context" is essentially an associative array of keys to variant data. 

Certain keys may have special meanings to the implementation - for example, we use 
"concept" to specify the general type of line being queried, like "saw enemy" or "on 
hit by bullets" or "player pushed context-sensitive button", and "who" to indicate the 
character performing the speech query ie which voice are we looking up. In our 
system every query must have at least those criteria, but mathematically they're like 
any other criterion. 
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Building a Query 


concept 

"OnHit" 

attacker 

"hunter" 

damage 

12.4 




CL4DPlayer::OnHit( 

CNPC * attacker, 
float fDamageHP ) 

{ 

// (assume gameplay code here) 


// 

ResponseQuery query; 

query.add(“concept”, “onHit”); 

query.add(“attacker”, 

attacker->GetClassName() ); 
query.add(“damage”, fDamageHP); 

Speak( query ); 


The contexts in a query are built up from many sources. 

First is the function that actually starts the query. It creates the query object and 
populates it with the basic information of the event you want the character to talk 
about, such as the general type of line you're searching for and event-specific info. 
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Building a Query 


concept 

"On Hit" 

attacker 

"hunter" 

damage 

12.4 


hitpoints 

78 

ammo 

43 

nearest_ 

Ally 

"coach" 

nearest_ 
ally dist 

733.0 

current_ 

weapon 

"Axe" 





Procedurally calculated 
at query time 


Then you call through to the base Speak() implementation, which starts to add in 
facts about the character who's speaking. This is when you procedurally pull in every 
fact that might be relevant to looking up speech, such as the character's health, 
weapon, nearby friends, any other local data or functions. The base Speak() member 
adds each of these to the table. You can chain through to ancestors' implementations 
as well, of course. 
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Building a Query 

/(()) + E + E 


concept 

"On Hit" 

attacker 

"hunter" 

damage 

12.4 


hitpoints 

78 

ammo 

43 

nearest_ 

Ally 

"coach" 

nearest_ 
ally dist 

733.0 

current_ 

weapon 

"Axe" 




times_ 

healed 

4 

suit_ 

complaints 

2 

zombies_ 

killed 

204 

times_used 

_axe 

111 

times_used 

shotgun 

93 



persistent store (as 
instance members / 
internal table/ etc) 


Then there's the persistent store inside the character, arbitrary data that can be 
written either by code or by writer-generated rules. This is where we store things like 
how many times a particular line has been said, events that happened previously, and 
so on. It's a table of arbitrary keynames and whatever the dialog rules have set. Add 
these to the associative array also. 
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Then you merge in any procedural state about the world in general; current map, 
extant entity count, and so on. The world can have a persistent memory store as well, 
just like individual characters. 


58 











































GAME DEVELOPERS CONFERENCE 


^GDCONF.I 


Building a Query 

/() + £+£ + 

'-^^ 


< 

k 1 

1 1 


m 

1 1 

1 k , 

nr 

k 


k 

1 k 1 

1 k , 

m 

k ] 

1 k , 


k 

/ 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 


query 


Take all of these sources of data, concatenate them all into one big associative array, 
and that's your query. It contains all the facts you'll use to select a line. 
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Thinking of dialog as a pile of rules 

When seeing the player, say 
"Look! It's Batman!" 

But if the player Is in shadow, then say 
"I think I see Batman!" 

But if this is the Penguin's Hideout level, then say 
"Kwak! Kwak! I think I see Batman!" 

But if this Is the Penguin's Hideout and the Penguin is apprehended, say 
"That's Batman! Get him for what he did to the boss!" 

But if this is the Penguin's Hideout and there's no friends around, say 
"Oh no Batman! Please don't hurt me!" 

But if the player is Catwoman, say 
"It's the kitty kat!" 

But if the player is Catwoman and Poison Ivy is alive, say 
"Hey cat, the boss wants a word with you" .... 


It's also natural to think of dialog as a system of general rules superceded by 
exceptions for particular circumstances. If a thug sees Batman, he says "hey look. 
Batman", unless he's a Penguin thug, unless he's a Penguin thug and the Penguin is 
arrested, unless he's alone, unless etc etc etc. This is a really comfortable way to think 
about behavior - as a hierachy of increasingly specific exceptions sitting on top of a 
general baseline. 
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Criterion 

• A function that tests a fact . 

- eg a key->f unc () pair that ''matches" or "fails" a fact. 

- The predicate may be an equality, a range, or a function. 

• { Query["who"] == "bill" } 

• { Query["hitpoints"] > 30 && Query["hitpoints"] < 60 } 

• {lsPrimeNumber( Query["nearbyEnemies"] ) == true } 


If a "fact" is a single piece of state about the world, then a "criterion" is a single 
function that tests a fact for truth. Like "The speaker is Bill" or "hitpoints are between 
30 and 60." I'm using "function" here in the computer science sense of some 
arbitrary conditional the returns true or false on a particular fact. You could use an 
actual function pointer if you really wanted to, but it's hardly ever necessary; typically 
we represent all of our criteria as numerical comparisons to make them more 
efficient. (That's later in the talk.) 
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Rule 

• A tuple of criteria to match against a query. 

- If all criterion are true, the rule "matches" 

- If any criterion has no matching fact in the query, it 
rejects. 

• Many rules may match a query, so: 

- A scoring function (to pick specific rules over general 
ones). 

- We use a simple one: # of criteria matched. 


A rule is a a tuple of criteria that all have to be true. If one is false, or one mentions a 
fact not in the query, then the rule is considered to reject. 

Many rules may match a query. If you have a very specific "oh look a zombie is on the 
merry-go-round next to the ice cream machine" rule, then the "oh look a zombie" 
general rule will probably match also. So you need a scoring function to pick specific 
rules over general ones. You can write that lots of different ways; have different 
weights for criteria and so on. The scoring function that worked best for us was the 
simplest one imaginable - the number of criteria in a rule. The more criteria a rule 
has, the more specific it is. 
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Rule Matching 


Query 


I { who: nick, concept: onHit, curMap:circus, health: 0.66, nearAllies: 2, hitBy: zombieclown } | 


{ who = nickj concept = onHit } “ouch!” 

{ who = nick, concept = onReload } -► “changing clips!" 

{ who = nick, concept = onHit, health < 0.3 } -► “aaargh I’m dying!” 

who = nick, concept = onHit, nearAllies > 1 } -► “oiv help!” 

who = nick, concept = onHit, curMap = circus } -► “This circus sucks! 
^F|^|>§>{ who = nick, concept = onHit, hitBy = zombieclown } -► “Stupid clown!” 
p { who = nick, concept = onHit, hitBy = zombieclown, curMap = circus} ^ 

' “I hate circus clowns!” 



Here's a simple example of how you might match a query against some rules. You can 
see the facts in the query. The first rule matches, because both of its criteria are true. 
The second one fails because the "concept' criterion is wrong. The third one fails 
because the "health" criterion is wrong. The rest of the rules all have additional, more 
specific criteria, which match as well. 
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Rule Matching 


. Query 


|{ who: nick, concept: onHit, curMap:circus, health: 0.66, nearAllies: 2, hitBy: zombieclown } 
Rulel: { who = nick, concept = onHit } -► “ouch! "< ^ Score: 2 1 


Rule 4 
Rules 
Rules 
Rule? 


{ who = nick, concept = onHit, nearAllies > 1 } -► “ow help!” Score. 3 

{ who = nick, concept = onHit, curMap = circus } -► “This circus sucks!’ Score: 3 

{ who = nick, concept = onHit, hitBy = zombieclown } -► “Stupid clown!” Scor e: 3 


{ who = nick, concept = onHit, hitBy ^ 
-► “I hate circus clowns!” 


zombieclown, curMap = circus} 


Score: ^ 


So now we score the rules that passed. The simplest way is just to count the number 
of matching criteria. 

Rule 1 has two criteria, it's the general case, scores 2. 

Rule 4 has more, it's more specific, so scores 3. It'll always play in preference to the 
other when available. 

Rule 5 and 6 also match other specific criteria, scoring 3. They're all appropriate so 
you can choose randomly between them for variety. 

But rule 7 has more criteria than the rest. It scores higher, so is the most specific line, 
the one that plays. 
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Response 

• The payload of a rule 

• Can be anything 

• In our speech system, 
lists of scripts combining 
anim + lipsync + sound 

• Can contain intelligent 
logic also 


Response PlayerLedgeHangStartNamVet 

scene "scenes/NamVet/LedgeHangStartOl 
//I need a hand up! 

scene "scenes/NamVet/LedgeHangStart02 
//Soinembody pull me up! 

scene "scenes/NamVet/LedgeHangStartOS 
//Godammit, I'm hangin' off a ledge over here. 

scene "scenes/NamVet/LedgeHangStart04 

scene "scenes/NamVet/LedgeHangStartOS 
//Hey, people, I'm hangin' off a ledge over here! 

scene "scenes/NamVet/LedgeHangStart06 
'/Somebody come pull me up! 

scene "scenes/NamVet/LedgeHangStart07 

scene "scenes/NamVet/LedgeHangStartOS 
//Somebody come help me up! 

scene "scenes/NamVet/LedgeHangStart09 
//Somebody come grab me up off this ledge. 


The "response" is just whatever happens when a rule matches. You can have some 
intelligence here too. For example, we actually record a bunch of different variation 
for each line, put them in the same "response", and have the engine choose 
randomly between them when a rule matches; it's an easier way to have variety than 
creating a bunch of parallel rules. Or your "response" could be code, or executable 
script, or anything really. 
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Writeback and followup 



Response c3M2SafeRoo[nGambler 
{ 

scene "scenes/Gambler/worldc3MlBl7.vcd" then rochelle c3M2safeRoom2d 


// Shit. This swamp is going to ruin my white suit. 
scene "scenes/Gambler/worldc3M2B03.vcd" then gambler c3M2SafeRoomb2 
// These swamps don't agree with me. 
scene "scenes/Gambler/Worldc3M2B05.vcd" 

// I am not dying in this goddamn swamp. 

} 


Rule c3M2SafeRoomGambler 

{ 

criteria ConceptTalkidle Joined3 isGambler isNotSaidc3M2safeRoom ismapc3m2_swamp isinstartArea 
ApplyFacts "Saidc3M2SafeRoom :l:0,Talk:l:3. 088” 

Response c3M2SafeRoomGambler 

} 


So far what we have is an elaborate system of conditional choice - basically a 
rearranged if/else and switch mechanism. To make the system capable of memory 
and conversation, we need more. Let's take a look at how a particular rule works, in 
detail. In this case, one of the conversations that play at the beginning of a mission. 
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Writeback and followup 


Number of living 

Querying character 

Survivors > 3 

= "nick" 


{currentMap} == "c3m2_swamp 


Automatically polled 
every few seconds 


V 


Rule c3M2SafeRaDmGambler 


I {SaidC3M2SafeRoom} = 


3[^onceptTal kidl ned3j^isGatnbl e t^sNotSai dc3M2sal 
Apply Fact^ 

Response c3M2SafeRoo[nGainbl 



Each character in game polls itself every few seconds to see if it has any "I'm idle" 
dialog it wants to play. That's the "Talkidle" concept. This rule will match that concept 
if some other criteria are met: 

• Three survivors are present 

• The speaker is "Nick", the "gambler" 

• This line hasn't been said already 

• We are in the swamp map 

• We're in the start area. 
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Writeback and followup 0 


M 


stored context table 


Rule c3M2safeRoomGamBW 


_ !Pn Ceptra' __ 

”^plyFacts |"Saidc3M2SafeRooin:l:OtTa1k:l|3.C 




Expiration time 


Name 

“gambler” 1 

0 

zombi es_kined 

112 

0 

Molotovs_thrown 

4 

0 

SaidC3M2SafeRoom 

1 

0 

talking 

1 1 

now + 3.088” 


!?M2SafeRoom ismapc3m2_swamp IsInStartArea 


When this rule matches, it'll write a couple of facts back to nick's memory: in this 
case, that the line has been played, and that Nick is speaking for the next few 
seconds. The latter is an example to show that you can have automatic expiration 
times on a particular fact, if you want to prevent two successive bits of a running gag 
from being played too close together. 
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Writeback and followup 



Response c3M2SafeRoomGamb1er 

{ 

scene "scenes/Gamb1er/worldc3MlBl7.vcd" then rochelle c3M2safeRoom2d 


// Shit. This swamp is going to ruin my white suit. 
scene "scenes/Gafflbler/worldc3M2B03.vcd" then gambler c3M2SafeRoomb2 
// These swamps don't agree with me. 
scene "scenes/Gambler/Worldc3M2B05.vcd" 

// I am not dying in this goddamn swamp. 

} 


Rule c3M2SafeRoomGambler 

{ 

criteria ConceptTalkidle Joined3 isGambler isNotSaidc3M2safeRoom ismapc3m2_swamp isinstartArea 
ApplyFacts "Saidc3M2SafeRoom :l:0,Talk:l:3. 088” 

Response c3M2SafeRoomGambler 

} 


Now look at those "then" clauses. What they mean is: once the line has finished, 
automatically trigger *another* concept (specified there) to the specified character. 
"Then rochelle C3M2SafeRoom2d" means that a "C3M2SafeRoom2d" concept is sent 
to Rochelle (the TV producer) after Nick finishes saying his line. She in turn will do a 
lookup in her rule database and find if there is a reply she wants to say. 
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Rochelle does have a reply. She says it; that in turn has another "then" followup that 
dispatches back to Nick, who has a reply of his own, and so on. 
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Writeback and followup 


Response c3M2SafeRoomGamb1er 

{ 

scene "scenes/Gamb1er/worldc3MlBl7.vcd" then rochelle c3M2safeRoom2d 
// Shit. This swamp is going t 
scene "scenes/Gambler/worldc3M2B03. vcd’V 
// These swamps don't agree u 


my sun . —— 

^_^^n gambler c3M2SafeRoomb2^ 


Response C3M2SafeRoomb2Gambler 

scene "scenes/Gambl er/worl dc3M2B01.vcd" ^hen mecham’c c3M2SafeRo omb^ ^ 

//This swamp is just a cesspooTlTn dii Li.ii - - 

scene "scenes/Gambler/worldc3M2B02.vcd" //i can feel my feet growing fungus. 
} 


Response c3M2SafeRoomb3Mechanic 
{ 

scene "scenes/Mechanic/worldc3MlB01.vcd" //Nick does have a point. 


Or maybe the other lines gets chosen randomly. Maybe instead of dispatching the 
line to Rochelle he dispatches it to himself. Then he has another couple of lines; "I 
can feel my feet growing fungus" or "This swamp is just a cesspool for disease." The 
latter one has *another* followup to Ellis. Each time the game plays out, it'll 
randomly select a different change, a different experience, without needing any 
special programmer code at all. The writers can build it all themselves, quite easily. 

This approach also means you query the followup line when the callback happens, 
not when the first character starts to speak. The situation may have changed during 
the time it took the first line to be said. 


72 


















: DEVELOPERS CONFERENCE 


MARCH! 


^GDCONF.I 



Self-branching conversation 


This is a really cheap way to get this branching conversation effect that we use to 
create variety. Just by adding a couple of rules and recording some voice, you can add 
new outcomes, or merge paths back together. You can create a lot of possible paths 
really cheaply. 
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"then any" rules 

• Dispatches followup to all characters within earshot 

• Picks the highest-scoring rule from all of them 

• Most specific reply wins 

Response GoingToDieGambler 

scene "scenes/Gambler/GoingToDieOl.vcd" then any a11y_dying //I really screwed the pooch back there. 

crenp "Qrpnpc/f;amh1 pr/r;m’nnTnni pH? v/rH" rhan anv allv Hvinn //T nnl-t-a raUp hprt-pr ra pp nf 


Rule Got ngroDieCoachCoachGambler 

c rite ria Concept Pi aye rGoingXoDie 
^ Response GoingToDieGambler 


mddle of nowhere. 


isNotSpeaking isNotCoughing isGambler lsAnyoneNear200 


In addition to dispatching a followup to a specific character, you can send one to all 
nearby characters within earshot simultaneously, to see if any of them have a reply; 
and of those which have the best reply. 
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best match = 0 


best match = 2 


best match = 6 


scene "scenes/Gambler/GoingToDieOl.vcd" then any a11y_dying //I really screwed the pooch back there. 

crenp "Qrpnpc/f;amh1 pr/r;m’nnTnni pn? v/rH" rhan anv allv Hvinn //T nnl-t-a raUp hprt-pr ra pp nf mv^pl-f 


Rule Got ngroDieCoachCoachGambler 

c rite ria Concept Pi aye rGoingXoDie 
^ Response GoingToDieGambler 


mddle of nowhere. 


isNotSpeaking isNotCoughing isGambler lsAnyoneNear200 


So the rule goes out to everyone. And maybe Rochelle doesn't have any line at all for 
this situation, so she has a match score of zero. Maybe Ellis has kind of a generic line, 
so he matches with score 2. 
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scene "scenes/Gambler/GoingToDieOl.vcd" then any a11y_dying //I really screwed the pooch back there. 

crenp "Qrpnpc/f;amh1 pr/r;m’nnTnni pn? v/rH" rhan anv allv Hvinn //T nnl-t-a raUp hprt-pr ra pp nf mv^pl-f 


Rule Got ngroDieCoachCoachGambler 

c rite ria Concept Pi aye rGoingXoDie 
^ Response GoingToDieGambler 


mddle of nowhere. 


isNotSpeaking isNotCoughing isGambler lsAnyoneNear200 


But Coach, he likes to Coach people. He has specific lines for this situation. So, if he 
happens to be around, he'll match with the best score. 
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Not only does Coach tend to have the best match because he has specific "help my 
buddy out" lines, but he also has specific lines for each of the characters. They have 
an additional "if random number is less than 30" criteria so they don't get 
overplayed. Also, if somehow we added another survivor character for which he 
didn't have a specific line, it would automatically fall back to the general ones, and 
Coach would still have something to say. 

So all of this creates character for Coach, and an interaction between the survivors! 
Coach coaches - that's who he is. And if you're hurting and he happens to be around 
and he's healthy, he'll try to coach you along. If he isn't around, maybe someone else 
has something to say. If not, then Nick just complains to himself. It's all automatic and 
writers can add additional special cases without needing to change any code. 
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Each followup line is a new query! 

• Copew'"’ 'ranging situations 






/ule SawRidersPoster_coach 

criteria ConceptSawRidersPoster isNotinoanger iscoach isAnyoneNearby 
Response Coach_Likes_Riders // Hey, do you like the midnight riders? 
then Ellis RidersConversationl 


Rule RidersConversation_Ellis 
){ 

criteria RidersConversationl isNotinDanger isEllis IsAnyoneNearby 
Response Ellis_Likes_Riders // Yeah, they’re awesome! 


Query the followup line when the callback happens, not when the first character 
starts to speak. The situation may have changed during the time it took the first line 
to be said. For example, consider an interaction when coach talks about his favorite 
rock band, and Ellis agrees. Coach only sends a message to Ellis to look up his line 
o/fer Coach's line is finished. 
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Each followup line is a new query! 

• Copew''’ 'ranging situations 

X? 

/ule SawRidersPoster_coach 

criteria ConceptSawRidersPoster isNotinoanger iscoach isAnyoneNearby 
Response Coach_Likes_Riders // Hey, do you like the midnight riders? 
then Ellis RidersConversationl 



Rule RidersConversation_Ellis 


criteria RidersConversationl is Ellis IsAnyoneNearby 

Response Ellis_Likes_Riders //yeah, the^'e awesome! 


That's to handle cases where, say, a zombie appears and starts chewing on Ellis while 
Coach is talking. In this case you do not want Ellis to continue blabbing about the 
Midnight Riders. You want him to interrupt the conversation and talk about 
something else. 

Because Coach sends a message to Ellis at the end of Coach's line, Ellis does a lookup 
for a reply based on the context at exactly the moment he begins speaking. In that 
case, the IsNotInDanger criterion is no longer true; a zombie is nearby. So the 
conversation self-terminates because the criteria for its existence are no longer true. 
You don't need any kind of explicit interruption mechanism. 
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Corrolaries 

• The followup line is selected after the first 
character speaks, when the second one replies 

- To allow rules to adapt to changed state 

• There's no "cutscene" entity that grabs both 
characters. 

- Just successive bits of dialog and statekeeping 

• Cut long speeches up into little self-followup pieces 


That gets you out of having to build explicit "conversation" entities and glue down 
both characters while they're speaking and have a means of handling interruptions, 
etc. 

It's also worthwhile to cut up long monologues by a single character into short pieces, 
where each line sends a "followup" back to the speaker to trigger the next. That's a 
simple way to bail out of long speeches if something happens, or allow writers to 
create additional conversation branches where another character actually breaks in 
on the speech if they happen to be present. 
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Code as Content 

• Replace programmer work in a uniformly 
managable way 

• Fewer dependencies 

• Faster (or absent!) compile step 

• Writers can work simultaneously on different 
characters 

• Hot swapping & dynamic reloading 


This blurs the line between code and content, with a number of salutary effects. 
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Humorous video. 

Video available via 

http://assemblvrequired.crashworks.org/gdc2012-dvnamic-dialog/ 
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The Machine-Writer Interface 


Now let's talk a bit about how to make a system that is comfortable and powerful for 
writers to work in. 

Photo credit: bios [bible] robot by Matthias Gommel, Martina Haitz, Jan Zappe 
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In fact, what better place to see how writers make code than interactive fiction? The 
Inform 7 language/system, used for making text adventures and interactive fiction, 
has had this notion of rulebooks cascading from simple to general cases for years. 
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This is actual Inform source code. It looks like English, but it's actually a regular 
computer-parsable grammar. Inform has this very notion of rulebooks, where specific 
cases override general ones based on circumstances around them. As you can see 
this idea is very straightforward to represent in a natural way, and its inclusion in 
Inform suggests how applicable it is to the task of creating dialog and narrative. 
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Smart writers know what works for them. And your writers are smart. If they were 
not smart, they would not be writers. 

Programmers shouldn't force a workflow on writers. It's important that writers be 
able to iterate as freely and quickly as possible, and they have to be comfortable for 
that to happen. Programmers often have preconceptions about how writers think, 
when many writers are perfectly able to define how they'd like their tools to work. 
Design tools for your writers on your project, rather than some abstract idea of 
writers. Ask your writers what they want. 

This is a very early typewriter manufactured by the Sholes-Glidden company (later 
Remington), incidentally also the one that introduced the QWERTY keyboard. Mark 
Twain was one of the first writers to use one, because he loved gadgets. He didn't like 
this gadget, though; it didn't work well for him, and was unreliable. But he was 
perfectly capable of defining his own comfortable work environment better than 
Remington could. 

Photos from Wikipedia. 
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•txt files 


• The actual asset the 
engine loads 

• Simple recursive-descent 
grammar 

• Parsed at load time (for 
quick reloading and 
iteration) 

• Human readable but also 
easy to auto-generate 



One workflow is to simply write the script file that the engine loads directly. Ours has 
a straightforward recursive-descent grammar that is easy to parse and generate 
mechanically. A programmer can simply write the script in this format. I guess. It's not 
very convenient. 
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Generating s cript from easier tools 


When seeing the player, say 
"Look! It's Batman!" 



But if the player is in shadow, then say 
"I think I see Batman!" 

But if this is the Penguin's Hideout level, 
then say 

"Kwak! Kwak! I think I see Batman!" 

But if this is the Penguin's Hideout and 
the Penguin is apprehended, say 
"That's Batman! Get him for what he 
did to the boss!" 


Rule ThugSeeBatman 

concept OnSeePlayer 
criteria IsThug 

response Thug_LookltsBatman 

} 


Or, you can come up with a simpler specification language for writers to work in, and 
then cook that into script files. For example, consider the handwavey Batman 
example I showed earlier. Although these rules are specified informally, you can see 
how each of them could be mechanically transformed into a formal spec. 
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Or, you can come up with a simpler specification language for writers to work in, and 
then cook that into script files. For example, consider the handwavey Batman 
example I showed earlier. Although these rules are specified informally, you can see 
how each of them could be mechanically transformed into a formal spec. 


89 










: DEVELOPERS CONFERENCE 


MARCH! 


^GDCONF.I 


Generating script from easier tools 


When seeing the player, say 
"Look! It's Batman!" 

But if the player is in shadow, then say 
"I think I see Batman!" 


But if this is the Penguin's Hideout level, 
then say 

"Kwak! Kwak! I think I see Batman!" 


Rule PenguinThugSeeBatman 
{ 

concept OnSeePlayer 
criteria IsPenguinThug 
response PenguinThug_SeeBatman 

} 


But if this is the Penguin's Hideout and 
the Penguin is apprehended, say 
"That's Batman! Get him for what he 
did to the boss!" 


Or, you can come up with a simpler specification language for writers to work in, and 
then cook that into script files. For example, consider the handwavey Batman 
example I showed earlier. Although these rules are specified informally, you can see 
how each of them could be mechanically transformed into a formal spec. 
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Generating script from easier tools 


When seeing the player, say 
"Look! It's Batman!" 

But if the player is in shadow, then say 
"I think I see Batman!" 

But if this is the Penguin's Hideout level, 
then say 

"Kwak! Kwak! I think I see Batman!" 


But if this is the Penguin's Hideout and 
the Penguin is apprehended, say 
"That's Batman! Get him for what he 
did to the boss!" 


Rule PenguinThugSeeBatman_Act4 
{ 

concept OnSeePlayer 
criteria IsPenguinThug 
IsPenguinJailed 

response PenguinThug_SeeBatman_NoBoss 


Or, you can come up with a simpler specification language for writers to work in, and 
then cook that into script files. For example, consider the handwavey Batman 
example I showed earlier. Although these rules are specified informally, you can see 
how each of them could be mechanically transformed into a formal spec. 
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With Inform 7, you can specify these rules formally, even if they look like English. So, 
since this is a parsable computer grammar... 
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Generating script from easier tools 



... it too can be translated directly into the internal representation. 
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Excel spreadsheet 


Response 

npc^dota hero omniknight 

concept 

criteria 

Omni rival 02 

iEorH?£n" 

Kill 

xscnemychen 

omni.rival 03 

S^?^rin;er^ri^s^l- 

Kill 


omni.rival 04 


Kill 


omni_rival_05 

Lifestealer, I will find what 

Kill 

XsEnemytife stealer 

omni.rival 06 


Kill 

IsEnemyweaver 

omni_rival_07 

overestimated you, Bane. 

Kill 

IsEnemysane 

omni rival 08 


Kill 

IsEnemyTinker 

omni rival 09 

is L impure ;oul. ’’ '' 

Kill 


omni.rival_10 

The omniscience would like a 

Kill 

IsEnemyzeus 

omni_rival_12 

sefreHor TrlasS;." 

Kill 

tsEnemywarlock 


Rules, comments, concepts, 
criteria entered as columns 
in a spreadsheet. 

Macro/tool exports the .xls 
into the response.txt format 
You can automatically 
export the .xls into the 
actor's callsheet for voice 
recording 

A convenient interchange 
format between tools 


Dota's writer uses an Excel spreadsheet; and that's fine! Some writers like 
spreadsheets. There's a row for each bit of dialog, columns for the criteria, and we 
use a macro to export from this to the engine's format. An advantage of this system is 
that it keeps all of your information about voice in a common place; we can use the 
same .xls to track engine rules and data about the voice as it moves through casting, 
recording, and audio processing. We can export from this spreadsheet to both the 
engine's script and also the physical paper script that the actor takes into the 
recording booth. 
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Visual tools 



Or you can build a visual tool. I spent several weeks over one summer writing a 
gadget for writers to visualize their work and conversation flow - I haven't got a 
screenshot of it any more, but this is sort of what it looked like. But I fell into the trap 
of thinking about abstract "writers" rather than my writers. I sat down to write a tool 
and thought, "hm, what would writers like? Writers are creative people. Creative 
people like visual things. So what I need is a visual tool with drag and drop and little 
bubbles and..." 

But I was wrong! I showed it to my writers and it never got used. It was too restrictive 
and too simplified for them. What the writers on Left4Dead and Portal really wanted 
was... 
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FoxPro database (!) 



...a FoxPro database. 

Chet Faliszek and Erik Wolpaw were database administrators in a previous life. 
They're very comfortable with building databases, and were perfectly capable of 
building a FoxPro utility to manage all their work for them. And this worked great for 
them: they were able to corral enormous amounts of data, do batch-processing, 
write export scripts, store everything in one place. If I'd only asked them what they 
wanted, I could have spent my time writing them better FoxPro export tools or a 
frontend to some more usable database with the same features. 
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As a Script Feature 

• Implement a rules database on the C++ side 

• Expose bindings to script 

• Script tables convert neatly to queries, criteria lists 

- Criteria can be arbitrary functions (that map a fact's value 
to true or false) 

• Rule "responses" can be arbitrary script objects 

- Espec/o//y functions! 


You can also expose the rules database and its types as a feature in your script 
engine. Table-based script types map neatly to the notion of "facts" criteria lists, 
queries built as associative arrays; and your responses can be arbitrary script objects. 
By exposing bindings to your native-coded response engine, you can make it a script 
feature that's both convenient and performant. 
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You can also expose the rules database and its types as a feature in your script 
engine. Table-based script types map neatly to the notion of "facts" criteria lists, 
queries built as associative arrays; and your responses can be arbitrary script objects. 
By exposing bindings to your native-coded response engine, you can make it a script 
feature that's both convenient and performant. 
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Debugging Tools 


Print any query / fact tuple to console 

Log queries 

Log sources of facts 

- "where did 'has_quest_x' get set from?" 

Log all matched rules 

- "why did this one score highest?" 

Log all tested rules, and which criteria passed/failed 
Dump current facts on any object (procedural and stored) 

Hot swap / edit & continue 

Asset validation - check that .wav files are there when scripts are 
loaded; check consistency; etc 


Another important factor in usability is a rich set of debugging tools that can be used 
in-engine while the game is running. Make sure to write them! 
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Another humorous video. 

Video available via 

http://assemblvrequired.crashworks.org/gdc2012-dvnamic-dialog/ 
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• Not a relational database 

• A complex lookup function 
where each rule's key is a 
composite tuple of predicates 

• The query is a tuple of values 

• A rule "matches" if all predicates 
intersect with the query 

- (eg if the logical "AND" of all 
predicates called on the 
corresponding facts returns true) 


Principia Mathematica (Isaac Newton) 


Nerd time 


Now to some of the implementation details. 

This is not a relational database. You cannot represent this as an SQL query. If it were 
a relational database, you would need a row for each rule and a column for every 
possible criterion to appear, meaning that most rules would have thousands of NULL 
columns for all the criteria they do not care about. This is neither efficient nor 
convenient. 

In computer science terms what we have is a surjective lookup function. Each "rule" 
in the database is a key-value pair, where the value is the response and the key is an 
expected state of the world. In this case, the keys are not numbers or values, but 
complex predicate functions - in particular, a tuple of predicates, all of which must be 
true for the key to match. The predicate functions act upon the "query" object, which 
is a tuple of values. Another way to look at is that the predicates are global and look 
at the state of the world. 
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The naive implementation 


Query is a list of eg pair<string,variant> 

- aka "an associative array" 

Merge/catenate multiple fact dictionaries together to build up the query 

- aka "a union of associative arrays" 

For each rule: 

- For each criterion in the rule: 

• Look up the corresponding fact in the query 

• If missing or no match, reject rule 

- If all criteria match, add rule to "accept" list 
Return highest scoring rule 

For r rules, c facts in query, d criteria per rule: 

0( r X c X d) =: 0( n^) 


You can imagine the most straightforward way of doing this pretty easily. You start by 
adding together all of the sources of facts... 
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...into one giant associative array, by doing a merge operation (like adding dictionaries 
in Python)... 
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The naive implementation 


Query is a list of eg pair<string,variant> 

- aka "an associative array" 

Merge/catenate multiple fact dictionaries together to build up the query 

- aka "a union of associative arrays" 

For each rule: 

- For each criterion in the rule: 

• Look up the corresponding fact in the query 

• If missing or no match, reject rule 

- If all criteria match, add rule to "accept" list 
Return highest scoring rule 

For r rules, c facts in query, d criteria per rule: 

0( r X c X d) =: 0( n^) 

= "You're fired!" 


...and then doing the obvious thing. 

In cubic time. 

I pronounce cubic-time algorithms as "you're fired." 
We can do better. 
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Optimization #1: Sorted list linear walk 

• Sort the list of criteria in each rule and the facts in the query. 


Q 

A:8 

B:6 

C: 7 

D:5 

E : 3 

F : 0 

G :9 









R 

A>6 

B = 6 

E<5 

G = 9 





• If a criterion is missing 
from the query, reject. 

• For r rules, c facts in 
query, d criteria per 
rule: 

0( r X d ) or 0( r X c ) 

= 0(n2) 

= "you're still fired." 


First, simply sort the criteria and facts in each rule alphabetically. Then you can walk 
through them linearly, rather than having to search the query. Also, this makes it easy 
to early-reject when a rule has a criterion with no matching fact in the query. 
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Opt. #2: Skip the merge step 

/(()) 


A:8 

D:5 

E:3 

F:0 

t 




B:6 

G :9 







A>6 

B = 6 

E<5 

G = 9 


No need to merge query + 
procedural + stored + world 
fact tuples together before 
sorting 

Store character and 
procedural facts in sorted 
arrays 

Move search pointers in 
parallel while matching 
criteria 


Also, you don't need to actually merge the arrays. If you keep parallel pointers into 
each source of facts, then you can walk them individually and get mathematically the 
same result as actually merging the arrays, without having to actually perform the 
memcopy. 
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Opt. #3: Hierarchical partition 

• Pick a few keys that you include in every rule ( 
''concept" and "who" are good ones) 

• Make a tuple of them and hash 

• Partition the tables by that so you can quickly 
reject ones that don't match 

• For rules divided into p partitions, you get 
0( r/pxd) 


Next you can partition your rules. For example, if you know that every rule always has 
a "who" criterion identifying who is speaking. 
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Opt. #3: Hierarchical partition 

rule rule rule rule rule rule rule rule rule rule [ rule 1 rule 



Then there is no need to search every rule in the database for lines pertaining only to 
Nick. 
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Opt. #3: Hierarchical partition 
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You can bucket your rules by speaker, get a constant-time lookup into the partition 
containing just Nick's rules, and then search just his lines. 

You can also subdivide that partition further by concept, map, etc - anything else that 
you know to be a constant-value predicate present in each rule. 

You can also take those predicates - like "who=nick; concept=onreload ; map=swam" 
- concatenate, and hash them. That gives you a hash key you can use to bucket rules 
as finely as you like, rather than explicitly chopping them into partitions. That way 
you can specify arbitrarily many partitions based on how many keys you are hashing, 
so you can partition your rules as finely as you like. If you can get down to about fifty 
rules per bucket, and each rule has an average of eight criteria, you can do a lookup 
in less than a microsecond. 
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Opt #4; Partitioning rules by region 

• What about rules 
that only matter 
in one part of the 
world? 

• And facts that are 
only relevant 
there too? 



You can also explicitly partition rules and facts by region. Let's say you have a 
globetrotting European adventure. England and Spain have quests relevant only to 
those regions. When you're in England, you don't want to test all the rules that are 
relevant only to Spain quests; there is no chance that a line there will match. 
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Individual databases per region/act/etc 



So cut your rules up into individual databases by region. You'll always have the 
"global" rules which can play anywhere loaded (like "ouch" and "draw your sword!" 
and so on). 

But rules in other regions can be put in their own databases. If you're in the King 
Arthur level, you don't even need to keep, say, the Italy rules in memory. Leave them 
on disk. Stream dialog rules in with the level data. Then when you search for lines in 
England, you can check the England and Global databases in parallel. 

Photo of King Arthur from Monty Python and the Holy Grail 
Illustrations of England and Italy from Wikimedia Commons. 
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Do the same thing with fact sources. Facts relevant only to England quests can be 
stored along with other England-specific data. You can merge in the England tables 
while running one of its quests, and dump the entire table of England facts from 
memory when in some other region. 
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Next optimization: within each partition, search rules by decreasing score. If you 
match a six-criterion rule, there is no need to even test the five- and four-criteria 
rules; there's no way they'll be returned. 
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If you know a six-criterion rule has passed, there's no need to test the four-rule 
criteria. So sort by decreasing "score" and you don't need to test rules just to throw 
them out. 
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Opt. #6: Speed up the linear phase 

• The comparison of one fact vs criterion 

• "name" = "bob" 

• hitpoints > 25 && hitpoints < 75 

• numZombies < 3 


Next up you can accelerate the comparison of an individual criterion - eg "does name 
equal bob" and all those other building blocks. 
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Opt. #6: Speed up the linear phase 

Most comparisons can be represented as intervals on a number line, 

hitpoints > 25 && hitpoints <75 




-> +00 


25 75 

zombies > 5 


Almost every criterion I have encountered can be represented as an interval on a 
number line. 

Remember that IEEE754 supports comparing floating point numbers to infinity! 
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Opt. #6: Speed up the linear phase 


Most comparisons can be represented as intervals on a number line. 

"Use symbols, > 

name = “bob” = #3478 


not strings!" 


-oo -- 


I -+00 


name > 3478 && name < 3478 


Even string equality is an interval on a number line, if you use a symbol table or some 
other way of mapping strings to unique integers (as opposed to using const char * 
like a noob). 

You'll notice that even though I am asking == here, I actually use greater-than-or- 
equal AND less-than-or-equal to intersect to just "equal." This is so that every 
comparison can be performed using the exact same instruction stream. 
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Opt. #6: Speed up the linear phase 

So most criteria can be represented as a numerical function : 

a <x< b 


struct CriterionStatic 
{ 

float fa; 

ComparisonType_t ctype; 
bool Compare( float x ); 

}; 


bool CriterionStatic::Compare( float 

{ 

if ( ctype == EQUALS ) 
return x == fa; 

else if ( ctype == GREATER_THAN ) 
return x > fa; 

else if ( ctype == LESS_THAN_EQ ) 
return x <= fa; 

// etc ad infinitum 

} 


X ) 


It's possible to store a "comparison type" enum in each criterion and then switch or 
if-else between "equals", "greater", "greater-or-equal", "neq" etc comparisons 
between a parameter and a number. But this is a lot of additional branches. 
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All of those comparisons can be transformed into an a < x < b operation, or 
intersections thereof. Then you can represent every comparison as the same 
structure and use the exact same comparison code for each one. This reduces branch 
penalties drastically. 
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Opt. #6: Speed up the linear phase 

Reduce branch penalties by converting all comparisons to 
a > X > b intervals. 

In a discrete number line 
(like IEEE754 floating-point numbers), 


struct CriterionStatic 

{ 

float fa, fb; 

bool Compare( float x ) 

{ return x >= fa && fb 

}; 


x; } 


X > a O X > a+e 


To learn all about comparing 
floating-point numbers, see 
Bruce Dawson's blog: 

http://bit.ly/wQqozK 


You can also do this with floating point numbers. In any discrete number system, you 
can transform a strict greater-than comparison to a greater-or-equal comparison by 
adding an epsilon. Epsilon does not mean "an arbitrarily small floating point number", 
but has a specific definition in the context of comparing IEEE754 floats. Bruce 
Dawson's blog has lots of great information about comparing floatpoint numbers 
efficiently and the underlying details of their operation. 
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Op t tf7 - cx>- mad science land 


rch 


probler^ 


g a feVtrec 
-icalculation 


Principal Comportent AnalysiSctc 
lumped together in a partition 


the 


*>>^ tor quantization, clustering analysis, math galore 


Then you can do all sorts of other clever optimizations - representing the intervals as 
subspaces of an n-dimensional space, partitioning rules by principal component 
analysis, using r-trees and x-trees and... 

Don't. 
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In practice... 

• The spatial partitioning algorithm was a bridge too far. 

• Hierarchical hashed partition is fine 

• R-trees of Q-space are complicated and mind-bending 

- And they blow up the L2 cache too 

• Opt #6 lets us query across 10000 rules in microseconds 

• Can always do the R* thing if your data sets get Google¬ 
sized 

• (see bibliography at end) 


It's not worth it. It's a lot of extra complexity and in my experience not even faster; 
you end up blowing your cache more than you save time. If you just use the 
hierarchical partitioning mechanism, you can get your buckets down to a dozen or so 
rules apiece, and then finding the best rule in a bucket is less than a microsecond. 
The hierarchical technique is fast enough, and much simpler to code. 

You can always go back to the crazy-land algorithms if you end up with enormous 
data sets; the interface to the system will remain the same, so you can optimize the 
back end ad lib. 
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• Additive specialization = new quests and 
character types without modifying old code! 


By the way, this makes modeling and user-generated-content easier, because it's all 
additive. People can always add rules to the system without breaking old ones; and if 
you throw all the worldstate into each query, modders can add in new special cases 
for state that exists in the base product, but had no specific outcomes. So if a modder 
adds a new character class to the game, they can add in lines for the class, and even 
have old characters respond to it specifically, without needing to change the base 
product. 
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The Essential Bits: 

• A pattern-matching engine that does fuzzy 
search between a context tuple, and a set of 
rules that have criteria tuples. 


kevi: value 

i {ki=Vi,l<2 

=V2, k3=V3, ...} 

"hello" 

kev2: value 

1 {ki=Vi,k2 

:=V4, k3=V5, ...} 

"zombie!" 

kevj: value 

{k,=V.k2 

=V4, k3=Ve,...} 

<handwave> 

key4: value 

{ki=V8,k2 

;=V2, k3=V3, ...} 

"kittens" 

query 


rules 

responses 


( dialog ) 

zombie! r 

<handwave> 


So, a summary. If you want this kind of rule-driven matching behavior, what you need 
is a pattern matching engine of some kind. 
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The Essential Bits: 



• Building context at runtime from 

- state about the world 

- state about the character 

- state about the event triggering the speech 

• (ie, speech type, presence of enemies, if "reloading" what 
kind of ammo, etc) 



/I) + 


You want to build queries into your rule system by adding together as many facts 
about the world as possible; and you always want to throw all that state at the 
database each time, to enable writers to add new rules for new specific 
circumstances without requiring programmers to go and add additional data to the 
query. 
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The Essential Bits: 

• Followup rules: allow one line to trigger a query on 

- Another character 

- Any other character 

- All other characters 








•r? 





You need a way for one response to trigger a lookup on a different character when it 
has finished, to make conversations. 
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• Writeback of saved 
context to world or 
character 

• Creates running gags, 
memory 

• Enables real logic 


The Essential Bits: 


You need a way for a matched response to write state back to the world, to create 
memory and turing-completeness. 
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The Essential Bits: 

^ Jiof 1 Jf i 



• Convenient interface! 


• Enable writers to do 

1 1 : fi 

more work themselves. 







And it has to be convenient for YOUR writers to work with! The whole point of this is 
to make a system that's comfortable, friendly, and intuitive for writers to work 
autonomously without having to wait on programmers. The more easily and quickly 
writers can iterate, the better they will write! 
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A philosophical interlude 


ApLOTOTeXrif; / Aristotle 


A philosophical interlude; when I say "Zoey remembers she got shot", is this 
meaningful or do I just mean "this creates the illusion that Zoey remembers she got 
shot." She doesn't "remember" anything, she is just choosing a different canned 
recorded line to play based on the state of a few variables. 
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"Hamlet is upset about his dead father' 


THE TRAGEDIE OF 


HAMLET.Prir 

iceofDcnmarke. 

T^rimus. 

; Sama^Prima. 



_ 














_ 



Well, what if I said "In that movie, Hamlet is upset about his dead father"? 

I would actually mean "I saw a guy called Sir Laurence Olivier pretend to be Hamlet 
who is upset about his dead father." Actually what I really saw was a screen reflecting 
light projected through celluloid that on it had an image of Lawrence Olivier 
pretending to be Hamlet. But Hamlet is an imaginary person; what I really saw was a 
screen reflecting a picture of Laurence Olivier reading some words from a book 
written centuries earlier. 

The point is that whether a character remembers or feels something is intrinsically a 
projection by the player, which is sustained by convincing writing and performance. If 
the object on screen acts and makes sounds like a convincing human would, we 
imbue it with human feelings. The quality of writing and simulation is what creates 
the suspension of disbelief. 

Therefore it's important to make a system that enables writers to work comfortably 
and spontaneously. 

If the rule set is programmer defined, then you force writers to fill out a series 
of mad-libs, which is not going to generate quality content. 

Also, if the writers can't easily define new rules, then they won't 
spontaneously come up with ideas for special cases or new gags. 
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Opt. #7: Represent as spatial partition 

• If every criterion is a numeric range x e [a,b], then each one is 
an axis 

• and a rule R with c criteria is a c-dimensional region. 

• A query Q with q facts is a q-dimensional point. 

• All possible fact and criteria keys form a n-dimensional space. 

• Consider a query Q continuously infinite along all n axes not in q 

• Consider each dimension in n not present as an axis c e R to be 
an implicit criterion x e [ -oo, oo ] 

• So finding all rules R that match a query Q means enumerating 
which subspaces contain Q. 


By representing each context as an axis in an n-dimensional space, each possible 
rule's criterion vector as a c-dimensional subspace, and the query as a q-dimensional 
point, the problem of selecting responses becomes a spatial interval search for the 
most specific subspace containing (q), allowing lookups to occur in logarithmic time, 
le, consider the R-tree, which is a fast spatially sorted data structure used 
for eg Google Maps queries like "find all restaurants within 2km of here" 

You can use an R* or an X-tree to extend this concept from two to N 
dimensions. 

The rules database can be built offline, so insertion performance and 
unbalanced trees aren't a problem: you do the additional work to precompute 
perfectly balanced trees before the game ever runs. 

Maybe I invented this just so I could say "Q continuum" at work 
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Left4Dead2 contextual player dialog 


• 



□ 



Lt “ 11 if “ 

_ 



Players could actively trigger dialog by selecting it from this wheel. This would 
correspond to the "concept" of the speech query, and then the other contexts pick 
the specific line. 
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Dynamic Scripted Interactions 

• In addition to animation and speech, you can also 
trigger entire scripts. 

• Query facts can be bound to script keys 

• Eg, for a '"push button'' script that has parameters 


< $anim_name ; $speaker ; $target_object > 



Query: {concept=SEE_OBD, who=redbot^ tanget=button } 


-> match { "button_script” } 
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Accidentally Turing-complete 

You can do any kind of logic 
with this system; it has 

• An alphabet of symbols 

• A state tuple 

• Rules for 

- Writing to the state tuple 

- Conditional branches 

(ok, technically it is a Minsky register machine 
but that is Turing-equivalent) 


Incidentally this is enough to build any general-purpose program. It's turing complete. 
With conditional branches and stored state, you can do actual logic and computation 
in the system. 

That makes it possible for writers to implement flow charts in the dialog engine... 
which is the essence of a conversation tree 

Or running gags, or followup comments, etc. 


Picture of Alan Turing via Wikipedia 
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Accidentally Turing-complete 

A domain-specific language 

• Rules-based 

• Comfortable for dialog 

• And fully expressive scripting! 


• Tastes great 

• Anc/less filling! 


Thinking in rules is writer friendly but the fact that system is turing-complete means 
that you can express any logic with it. le, the system is a fully expressive domain- 
specific language. 

(too cumbersome for general-purpose code, but can be stretched to accommodate 
any special case) 


Picture of Alan Turing via Wikipedia 
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in Pseudo-Script... 


g_ResponseDB.AddRule ( 

criteria = [ Criterion( "concept", X(concept) { concept == “isClitnbing” } ) ], 
response = XCspeaker) { 

speaker.piayRandomwavC [ "vo.climbing.1", "vo.climbing.2", "vo.climbing.3” ] ) 

} 


) 


// and a more specific rule if it's snowing 
g_ResponseDB.AddRule( 

criteria = [ Criterion( "concept", X(concept) { concept == “isclimbing” } ), 


CriterionC "issnowing", XCfact) { fact >=!})], 


response = XCspeaker) { 

speaker.piayRandomwavC [ "vo.climbing_snow.l", "vo.climbing_snow.2” ] ) 

} 


) 


Example bindings to Squirrel, a scripting language we're experimenting with 
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Back in History: Half Life 2's 
"response rules" system 

• A small set of general speech concepts 

- "reloading", "help me", "covering" 

• Specialized by certain character criteria 

- Gender of character, current map 

- Optional factors: presence of enemies, health of 
player 


Back in history : the Half Life 2 "response rules system" 

A very simple database of general speech concepts like "reloading", "help 
me", specialized by a small set of criteria: gender of speaker, current map, 
some optional factors like the presence of enemies or health of player. 
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Back in History: Half Life 2's 
"response rules" system 


- vortigaunt.cpp - 


void CNPCVortigaunt::Use( CBaseEntity *pActivator, 
CBaseEntity *pCaller ) 

{ 

// If we haven't said hi, say that first 
if ( !SpokeConcept( TLK_HELLO ) ) 

{ 

Speak( TLK_HELLO ); 

} else { 

Speak( TLK_IDLE ); 

} 


Back in history : the Half Life 2 "response rules system" 

A very simple database of general speech concepts like "reloading", "help 
me", specialized by a small set of criteria: gender of speaker, current map, 
some optional factors like the presence of enemies or health of player. 

So you had just a single "TLK_HEALING" event, and then the system would try to pick 
the best, most specific line automatically based on all the other factors 
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Back in History: Half Life 2's 
"response rules" system 


- scripts/response/vortigaiint.txt — 


response "Vortigauntldle" 

{ 

scene "scenes/npc/vortigaunt/poet.vcd" 
scene "scenes/npc/vortigaunt/hopeless.vcd" 
scene "scenes/npc/vortigaunt/alldear.vcd" 
scene "scenes/npc/vortigaunt/prevail.vcd" 
scene "scenes/npc/vortigaunt/seenworse.vcd" 
scene "scenes/npc/vortigaunt/persevere.vcd" 
scene "scenes/npc/vortigaunt/worthless.vcd" 
scene "scenes/npc/vortigaunt/whereto.vcd" 


rule VortigauntTlkldle 


Back in history : the Half Life 2 "response rules system" 

A very simple database of general speech concepts like "reloading", "help 
me", specialized by a small set of criteria: gender of speaker, current map, 
some optional factors like the presence of enemies or health of player. 

So you had just a single "TLK_HEALING" event, and then the system would try to pick 
the best, most specific line automatically based on all the other factors 
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Feature I wish I had thought of 

• Self-disabling rules 

- "Don't say this more than once" 

- "Don't say this if it's been said in the last 60 seconds" 

• Had this on responses, but that meant a rule 
would match but no voice would play. 

• Writers had to make a special-case variable for 
each one-off line. 


Storing individual variables to remember which lines were said, and having to add 
criteria on the rules to prevent them matching twice, is lame. It would have been 
better to have some way for a response to remove itself from the database after 
playing. 


143 








DEVELOPERS CONFERENCE 2012 MARCH 5-9, 2012 WWW.GDCONF.I 


Why end-of-line callbacks are important 

• Source had a design flaw where speech couldn't call 
back to ganneplay when it was done 

• Hard-coded delays for followup lines 

• Required localized voice actors to match timings 
exactly 

• Speech/anim system must call back into the 
response database when the line is finished 
- Relying on timers and dead reckoning is clumsy 


144 








